Skip to content

Conversation

@abbycross
Copy link
Collaborator

@abbycross abbycross commented Jan 13, 2026

Closes #4144. cc: @pandasa123 @acastellane @ElePT

  • Include a high-level tl;dr: overview of the steps
  • remind users their serverless workloads won't show up on their Workloads table
  • be clear about which saved account is default (this applies not just to serverless)
  • where to go to find out about package versions/dependencies (also a larger question)
  • add info about when a job id is actually assigned
  • clearer connection with Functions?

@review-notebook-app
Copy link

Check out this pull request on  ReviewNB

See visual diffs & provide feedback on Jupyter Notebooks.


Powered by ReviewNB

@abbycross
Copy link
Collaborator Author

When @pandasa123 is back, need his feedback on the admonition regarding link-outs to the github.io page:

  • Language ok?
  • How many Serverless pages do we post the admonition on (just the intro, all of them, etc.)?

@abbycross
Copy link
Collaborator Author

Possible to state in our docs when the job_id is assigned in the process? - or will that be changing too? @ElePT

@ElePT
Copy link
Collaborator

ElePT commented Jan 29, 2026

Possible to state in our docs when the job_id is assigned in the process? - or will that be changing too? @ElePT

With Functions, we have a "serverless job_id" and a "runtime job_id". I assume that you are referring to the runtime one. I think that the platform changes will make things clearer but in the meantime, it won't hurt to add a bit more detail as to when the runtime job is expected to start. This behavior won't change this year.

Here's the gist: when a user calls function.run a serverless job is submitted. At the moment, this serverless job id doesn't show up in the workloads page. The serverless job will go through a series of statuses:
1.QUEUED
2.INITIALIZING
3.RUNNING
4.SUCCESS (error, stopped, etc are also possible)

If the function providers supports it, the RUNNING status will be split up into "sub-statuses":

  1. RUNNING: MAPPING
  2. RUNNING: OPTIMIZING FOR HARDWARE
  3. RUNNING: WAITING FOR HARDWARE
  4. RUNNING: EXECUTING ON HARDWARE
  5. RUNNING: POST_PROCESSING

When the sub-status says RUNNING: WAITING FOR HARDWARE, we know that a runtime job has been submitted, and the corresponding entry is expected to appear in the workloads table. If the function doesn't implement sub-statuses, we expect the runtime job to appear at some point in the RUNNING status of the serverless job, but we won't be able to accurately know when. In any case, that point will hardly ever be the beginning of RUNNING, which is what many users expect and get confused by.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

Update "write your first serverless program" guide

2 participants